Method and Apparatus for Automated Bill Timeline

ABSTRACT

A computer-implemented method for displaying a plurality of bill due dates, the method comprising: displaying an account identifier for each bill in the plurality of bills; showing a timeline with a due date indicator for each bill in the plurality of bills, the timeline disposed proximate to the account identifier; and wherein each of the account identifiers and timelines are disposed along an axis relative to the other account identifiers and timelines

RELATED CASES

This application is a continuation of U.S. application Ser. No.14/285,520, entitled “METHOD AND APPARATUS FOR AUTOMATED BILL TIMELINE”,filed 22 May 2014, now U.S. Pat. No. 9,978,046, issued 22 May 2018(Attorney Docket No. CNNX 1001-3) which is a continuation of U.S.application Ser. No. 13/661,989, filed 26 Oct. 2012, entitled “METHODAND APPARATUS FOR AUTOMATED BILL TIMELINE”, now U.S. Pat. No. 8,738,477,issued 27 May 2014, which is a non-provisional application of U.S.Provisional Application No. 61/557,908, filed 10 Nov. 2011, entitled“Method and Apparatus for Automated Bill Timeline”.

BACKGROUND Field

This disclosure is generally related to an inbound message managementsystem that individuals use in order to manage communications frombusinesses with which they have relationships. More specifically, thisdisclosure is related to providing automated processing of the inboundcommunications to facilitate more efficient use of the communications bythe individual.

Related Art

Programs and systems such as Quicken and Mint, now both owned by IntuitInc., as well as PageOnce, can accept direct input of financialinstitution access credentials to allow aggregation of financialinformation for a household in a single place. Similarly, online billpayment systems from financial institutions such as Bank of America andUSAA have provided integration with billers via direct input ofindividual, or household, access credentials for the bill payer's site.These tools may in turn rely on other systems such as Yodlee forinterfacing with the financial institutions.

Other tools such as the Organizer product from OtherInbox canautomatically analyze, prioritize and summarize emails coming into auser's inbox from institutions. Still other tools such as TripIt allowindividual emails to be forwarded to a dedicated email address tofacilitate presenting a single view of travel-related information.

Additionally, university research projects such as RADAR (See, e.g.,“RADAR: A Personal Assistant that Learns to Reduce Email Overload,”Freed, Carbonell, et al., 2008) have focused on providing virtualassistants for processing and handling email to assist in performingtasks related to those emails.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 shows an architectural level schematic of a system in accordancewith an embodiment.

FIG. 2 shows a high level view of the data model of a system inaccordance with an embodiment.

FIG. 3 shows a user interface for an embodiment.

FIG. 4 shows a user interface for the bills timeline for an embodiment.

FIG. 5 shows a user interface for the details view for an embodiment

FIG. 6 shows a user interface for the anticipated and non-recurringbills timeline for an embodiment.

FIG. 7 shows a user interface for an embodiment.

FIG. 8 shows a user interface for an explanation of an anticipated billfor an embodiment.

FIG. 9 shows a user interface for editing an account for an embodiment.

FIG. 10 shows a user interface for adding a bill for an embodiment.

FIG. 11 is a process flow diagram for generating the timeline accordingto an embodiment.

DETAILED DESCRIPTION Overview

The discussion is organized as follows. First, an introductiondescribing some of the problems addressed by various embodiments will bepresented, followed by an explanation of terminology that will be usedthroughout the discussion. Then, a high level description of oneembodiment will be discussed at an architectural level along with a datamodel. Next, the user interface used by some embodiments will bediscussed in conjunction with the details of algorithms used by someembodiments. Lastly, various alternative embodiments are discussed.

Let's consider the Doe household with two adults, John and Jane, and acollege aged child, Sarah. The Doe household may have a wide array ofrelationships with financial institutions; billers such as utilities;brokerages; 401K companies; health care providers; retailers; insurancecompanies; and rewards programs. Information from these institutions mayflow into a variety of locations: bills might primarily flow into Jane'spersonal email account; brokerage statements might flow into John'spersonal email account; travel plans for Jane's work into her workemail; shopping reward credits into John's personal email; and, Sarah'sdebit card statements into her college email. It is desirable to providea snapshot that encompasses more than just finances. Such a snapshotshould include the wide variety of activities involved in running theDoe household.

We describe a system and various embodiments to provide a householdmanagement system with a graphical timeline display of bills. Thisenables a user to allow the system to automatically setup andpre-populate the system with most of the institutions they interact withwithout the need to laboriously manually enter the account information,and access credentials, at startup. Additionally, the system'saggregation and organization capabilities may have the effect of causingusers to opt in to more notices, coupons and other messages fromcompanies because the system will aggregate and manage the informationfor them effectively.

Terminology

Throughout this specification the following terms will be used:

Registered User, or User: An individual who wishes to use the serviceregisters as a user, e.g. registered user or user. To help with enablingthe aggregation of household information, each registered user can beassociated with one or more system accounts. Individuals can access thesystem using access credentials of their selection, e.g.username/password, secure tokens, one time passwords, OAuth (includingvariations such as Facebook, Gmail, Yahoo, etc.), and/or otherauthentication approaches. Once authenticated they can access theinformation about the system accounts with which their user isassociated.

System Account: A system account is an aggregation of information aboutmultiple registered users, providing the foundation for a snapshot of ahousehold. Each system account may have a primary registered user whocan add or remove additional registered users' access to the systemaccount.

Institution: An institution is an entity, such as a company, with whichregistered users have relationships. Examples include banks, airlines,electric companies, phone companies, brokerages, mutual fund companies,insurers, health care providers, rewards programs, stores, onlineretailers, and the like.

Institution Account: An institution account is a representation of arelationship between a registered user and an institution, e.g., a bankaccount, a brokerage account, an Amazon shopping account, a Bank ofAmerica checking account, and a frequent flyer program account. Manyinstitution accounts have a unique number, e.g. bank account number,rewards program number, Social Security number, email address. “Account”may be used as shorthand to refer to either institution accounts orsystem accounts, during this discussion, and the meaning will beapparent from the usage.

Online Identity: An online identity is a set of credentials that aregistered user uses to access an institution account. A single onlineidentity may provide access to multiple institution accounts, e.g. forthe Doe family, John's username/password accesses all of the Bank ofAmerica institution accounts for John's Social Security number.Similarly, a single institution account may be accessible with multipleonline identities, e.g. both Jane's username/password and John'susername/password can access the joint bank account.

Payment Methods: A payment method is a representation of a method forsystem accounts to pay bills, such as the use of credit cards, onlinebill pay (OLBP) services accessed via a web browser or a mobileapplication, debit cards, electronic fund transfer (EFTther pro) from anasset account, Paypal, pay-by-touch systems such as those that use nearfield communications, pay-by-mobile or cellphone, and manual payments.Payment methods facilitate use of the system account by registered usersto pay institution account bills.

Message Streams: Each registered user can associate one or more inboundmessage streams with one or more system accounts. Once a user hasestablished a message stream, the system imports and processes messagesfrom known institutions. The list of known institutions is generallymaintained in a master list for all users, but some embodiments mayallow per-user customizations, as well as feedback provided by users ofthe system to update the master list. For push notifications and webAPIs, relevant messages are imported.

System Overview

A system and processes to provide a household management system with agraphical timeline display of bills is described. The system will bedescribed with reference to FIG. 1 showing an architectural levelschematic of a system in accordance with an embodiment. Because FIG. 1is an architectural diagram, certain details are intentionally omittedto improve the clarity of the description. The discussion of FIG. 1 willbe organized as follows. First, the elements of the figure will bedescribed, followed by their interconnections. Then, the use of theelements in the system will be described in greater detail.

FIG. 1 includes a system 100. The system includes message sources 110,message management system 120, and end points 130. The message sources110 include email account 111, email account 112, web API 113, and pushnotification 114. The message management system 120 includes acontroller 121 and storage 122. The end points 130 include computer 131,computer 132, mobile 133, tablet 134, and TV 135. Computer 131 iscoupled in communication with a display 160 showing a user interfacegenerated by the message management system 120 in accordance with oneembodiment. Additionally, user input 150 to the computer 131 is shown.

The interconnection of the elements of system 100 will now be described.The message sources 110 are coupled in communication to the messagemanagement system 120 (indicated by double-headed line with arrows atend). The different sources may arrive via different mechanisms. Forexample, the email accounts 111-112 may be retrieved over a network,e.g. the internet, using one or more protocols, such as IMAP, POP,ActiveSync, Exchange protocol, MAPI. The web API 113 may be accessedover another network, or the same, e.g. private network, VPN, MPLScircuit, or internet, and may be any appropriate API, e.g. Yodlee,Quicken APIs, institution-specific API. Similarly, the push notification114 may come over a network such as the internet or over an alternativenetwork, e.g. SMS. All of the communications may be encrypted and, asappropriate, the decryption credentials may be available to the messagemanagement system 120 directly, or may be stored in storage 122 inencrypted form until additional input from an end point 130 provides thenecessary decryption information, e.g. input of a decryption passwordfrom a user on an end point. Additionally a variety of authenticationtechniques such as username/password, OAuth, Kerberos, and more can beused for the communications. Loosely speaking, the message sources 110can be viewed as either “pull” or “push” sources depending on how thedata reached the message management system 120. For example, emailaccount 111 might be accessed via IMAP over SSL in a pull fashion, e.g.controller 121 causes the email account 111 to be polled periodicallyand new messages retrieved. In contrast, email account 112 might beaccessed via ActiveSync in a push fashion, e.g. the email account 112notifies the controller 121 when new messages are available, optionallypushing them to the controller 121.

Controller 121 and storage 122 can be composed of one or more computersand computer systems coupled in communication with one another. They canalso be one or more virtual computing and/or storage resources. Forexample, controller 121 may be an Amazon EC2 instance and the storage122 an Amazon S3 storage. Other computing-as-service platforms such asForce.com from Salesforce, Rackspace, or Heroku could be used ratherthan implementing the message management system 120 on direct physicalcomputers or traditional virtual machines. Communications between thepotentially geographically distributed computing and storage resourcescomprising the message management system 120 are not shown.

The end points 130 are similarly coupled in communication to the messagemanagement system 120 (indicated by double-headed line with arrows atend). This communication is generally over a network such as theinternet, inclusive of the mobile internet via protocols such as EDGE,3G, LTE, WiFi, and WiMax. The end points 130 may communicate with themessage management system 120 using HTTP/HTTPS protocols and may beimplemented in one embodiment using a web interface or application toenable easy support of a range of end point device types. The mobile 133can be any mobile device with suitable data capabilities and a userinterface, e.g. iPhone, Android phone, Windows phone, Blackberry. Thetablet 134 can be any tablet computing device, e.g. iPad, iPod Touch,Android tablet, Blackberry tablet. The TV 135 can be a TV with built inweb support, for example Boxee, Plex or Google TV built in, or can be aTV in conjunction with an additional device (not shown and oftenreferred to as a set-top box) such as a Google TV, Boxee, Plex, AppleTV, or the like. According to some embodiments, the end points 130 areany web-enabled device supporting reasonable full HTML rendering, andthe feature set available on a device may be limited depending on theHTML rendering capabilities. In other embodiments, a custom, or native,user interface is prepared for the device, e.g. a device with a morelimited web browser but a native widget set might receive a customapplication. Similarly, some recent mobile devices, tablet devices, andTVs support an “application store” concept and custom applications couldbe targeted at such embodiments. In certain situations, the environmentmay be executing remotely and rendered on the TV, e.g. cable headedcomputers execute the application and cause the display to be renderedand process user inputs passed back over the system. The display 160 iscoupled in communication with the computer 131 and the computer 131 iscapable of receiving user input 150, e.g. via keyboard, mouse,track-pad, touch gestures (optionally on display 160).

The communication is often bidirectional with the end points 130directly making requests to the message management system 120 and themessage management system 120 directly making requests to the messagesources 110.

Having described the elements of FIG. 1 and their interconnections, thesystem will be described in greater detail in conjunction with FIG. 2,showing a high level view of the data model of a system in accordancewith an embodiment.

FIG. 2 shows the relationship between registered users 210, systemaccounts 220, relationships 230, and institutions 240. The lines betweenthese boxes, together with the notations at the line ends, describe thecardinality of the relationships, e.g. each registered user 210 isrelated to one or more system accounts 220; each system account 220 isassociated with many relationships 230, but each relationship 230 isassociated with exactly one system account 220. The singular and theplural are used interchangeably in discussing the elements of FIG. 2 forclarity to better focus on describing the data model which the diagramclearly describes. Dotted boxes are used to highlight additional typesof associated data in the data model, e.g. message streams 211, messages212, payment methods 221, institution accounts 231, online identities232, documents 233, and message parsing and recognition information 241.Additionally, not shown, a mapping 243 is maintained between onlineidentities 232 and institutions 240. In one embodiment, the messages 212in the message stream 211 can be analyzed to identify bills 252 whichcan be associated with an institution account 231. Additionally,manually entered bills can be stored with the bills 252 in someembodiments. Bill predictions 254, is used by some embodiments to trackanticipated bills. In some embodiments, the bills 252 and the billpredictions 254 are stored as a single object with additional dataindicating whether the item is an actual vs. predicted bill as well aswhether the bill was entered manually or if it corresponds to a messagein messages 212.

In one embodiment, adding a manual bill may create a private, relativeto other users, institution, e.g. in institution 240, as well as aninstitution account 231. These private institutions can be tracked bythe operator of the system 120 to identify potential additionalinstitutions to identify from messages. For example, if a meaningfulnumber of users all have XYZ utility bills, then the XYZ utility mightbe made into a public institution with appropriate message parsing andrecognition information 241 added. Additionally, some embodiments mayallow registered users 210 to submit messages 212 to the system 120 forspecific processing, e.g. the system did not detect institution XYZ, butthe user wants messages from that institution identified. Submittingsuch a message may in such an embodiment trigger the creation of a newinstitution and the generation (automatically or with humanintervention) of one or more rules to be added to message parsing andrecognition information 241 for automatically handling those messagesgoing forward. Such additional parsing and recognition capability can bekept private to the user who requested it, or alternatively, in oneembodiment, can be added as additional rules that will benefit otherusers of the system as well.

Additionally, in some embodiments receipt of a bill into bills 252 maytrigger automatic creation of one or more entries in an accountingsystem linked to the system account 220 (not shown). For example, onereceipt of a bill entries in Quickbooks could be automatically createdto record the receipt of the bill. For businesses, this feature mayreduce book keeping costs and improve accounting processes.

FIG. 2 is only one possible data model used by an embodiment; other datamodels may be used. It should be understood that the data model in FIG.2 can be implemented in one or more databases, object relational mapping(ORM) systems, and/or any other appropriate data storage. If a SQL-styledatabase is used, each box loosely corresponds to a table with rows ofthe tables containing the appropriate contents. For example, theregistered users 210 could be stored as a table with one row perregistered user, and an intermediate table would be used to connect theregistered user table with the system accounts table to support themany-to-many relationship. In other data storage approaches,intermediate tables might not be required, and for that reason suchintermediate, or join tables, are omitted from the data model of FIG. 2.The data and data model of FIG. 2 can be stored in the storage 122 andmanaged by the controller 121.

The storage 122 includes both institution data and user data. Theinstitution data can include email domain names and addresses(institutional whitelist), as well as a collection of rules used toanalyze emails originating from that institution. The user data caninclude a list of business relationships associated with each systemaccount. Each relationship 230 can include the name of the institution,a list of institution accounts 231 that the registered users associatedwith that system account have established with that institution, onlineidentities 232, and documents 233. In this embodiment, payment methods221 can be associated with system accounts 220. This can facilitateeasier bill payment, e.g. you usually pay your phone bill with your BankX Credit Card.

Additionally, the information about institutions 240 can includeinformation to handle proxy delivery services. Example #1: Schwab andother brokerages use a service to send out certain proxy materials.Emails come from id@proxyvote.com. Emails received from proxyvote.comcan be associated with the original institution (in this case Schwab)and processed as such. Ultimately, actions can be proposed and/or takenwith respect to these email, helping manage that user's household.Example #2: Bank of America offers a service called e-bills. Users ofthe service receive notices from Bank of America when their bills comedue. These notices can be associated back to the appropriate billinginstitution to make sense to the end user. Such linkages can use amixture of account information from the proxied emails, as well asoptional manual corrections and/or adjustments by registered users.

Returning to the description of the system 100, we will focus on theinitial setup and first use of the example Doe household of John, Janeand their college aged child, Sarah to motivate the operation of thesystem. A household member, Jane, connects to the system 100 via an endpoint 130 such as computer 131 using a web browser, e.g. Chrome,Firefox, Internet Explorer, or Safari, and becomes a registered user.Once registered, Jane establishes the Doe Family system account. Thisinformation is stored by the controller 121 in the storage 122. Next,Jane provides login information for one message source 110, e.g. herpersonal GMail email account, email account 111. The controller 121 canthen access the email account 111 and begin to automatically identifythe household's institution accounts, discussed in greater detail below,and create a dashboard for the household. Later, John can become aregistered user and associate his message streams, e.g. email accounts,with the Doe Family system account. Additionally, the parents can createa second system account for their college aged child, Sarah, e.g.“Sarah's Accounts,” which both they and she can monitor.

Throughout this example, computer 131 will be used as the endpoint 130and the users can view the output of the system on the display 160 andcan interact with system by providing user input 150 to the computer131. That user input 150 may be communicated by the computer 131 to themessage management system 120 to eventually cause an update to thedisplay 160.

As shown in FIG. 2, the contents of the messages can be stored in themessage stream 211 associated with a specific registered user 210. Thisprovides the system account, or Doe Family in this example, access tothe messages without requiring sharing, among household members, ofpasswords or access credentials.

Additionally, display settings for the underlying messages may beavailable in some embodiments. In one embodiment three display settingsare available for each message: joint, shared or private. Thisinformation is used, along with message ownership information, tocontrol the display of objects in the user interface:

-   -   Joint—all registered users of the system account have equal        control and access to all the information (emails and documents)        that is not segregated by user.    -   Shared—all registered users see the information in their        dashboards, but only the message recipient can control the        display status.    -   Private—only the registered user to whom the message was        directed can view the message in their user interface.

The specific display settings can be varied in different embodiments. Itis valuable to have default display settings for different message typesand/or institution type that can then be further customized by users.The display settings serve to limit clutter and thus better manageusers' attention budgets. In some embodiments, the settings may alsoserve a security function.

For “pull” oriented message sources 110, the message management system120 may periodically access the message sources 110 to obtain newinformation. The polling rate may be set automatically by the systemand, in some instances, may be further customized by registered users,e.g. check my email every 15 minutes. During the pull process, relevantmessages are imported into the message stream 211 for that registereduser 210. See below for further discussion of email processing. For“push” oriented message sources 110, the message management system 120can respond to push notifications by storing relevant messages into themessage stream.

The message management system 120 processes the message streams 211 fora system account 220 to create a unified dashboard that can be viewed onthe end points 130. One or more types of summarized versions of themessage may be created for each original message according to oneembodiment: alerts and snaplets.

Alerts can be used to represent certain messages in displays on endpoints 130. Alerts are used for displaying important information inmessages in a way that allows the end user to review their messagecontents without navigating to each message and having to click/touchthrough each one. In some embodiments, alerts can be used for messagesthat contain account activity information that generally does notrequire follow up. Examples could include: welcome messages, passwordchanged, new biller created, account activity, new PIN confirmed,deposit posted, periodic summaries, bill reminders, proxy materials,many travel related messages, stock quotes, stock alerts, and socialnetwork notifications (e.g., Facebook, Twitter, LinkedIn notifications).In some embodiments, social network notifications are separatelycategorized from other types of alerts. In contrast, in someembodiments, snaplets require user action to complete a task, e.g. pay abill that is due, complete a purchase such as a Groupon coupon, voteproxy materials, obtain a document, renew driver'slicense/registration/prescription. Additionally, snaplets can be moreheavily formatted to extract key actionable data such as amounts/duedates, whereas alerts may retain the original text, while stripping outformatting and boilerplate to enable easy scanning.

A snaplet is a text or media message transformed and/or extracted intoformatted data with fields specifically extracted from the message. Theextracted fields are system defined for a given message type. A snapletis formatted by identifying a relevant message, extracting keyinformation for that type of message and storing it in a structuredformat. An alert is a text or media message transformed and/or extractedinto text with most formatting and boilerplate removed either bysummarizing the original message or extracting key textual elements.

Some sample alerts are shown here:

Example Alert #1:

Chase: Your Daily Account Summary

From Chase Feb. 12, 2010 '4567

End of day balance: $2,164.61

Total deposits: $0.00

Total withdrawals: $0.0

Example Alert #2:

Chase: Your Set Transaction Amount

Exceeded Alert From Chase Card Services

Feb. 11, 2010 1234

A transaction exceeded ($ USD) 1.00.

Example Alert #3:

Chase: Your ATM Withdrawal Feb. 11, 2010 '4567

A $120.00 ATM withdrawal exceeded your

$100.00 Alert limit.

As you can see, this format for messages is suitable for easy scanningor swiping on a touch device without the need to manually providinginput to go from message to message. Consider some snaplets in contrast;the fields from each snaplet enable easy composition into a single lineactionable representation of the underlying message on end points 130:

PAYMENT CalWater '1234 $113.14 Due: Feb. 22, 2010

PAYMENT PG&E '29-6 $731.48 Due: Mar. 1, 2010

CHECKIN Southwest SFO-LAX 2:15 pm On: Feb. 14, 2010

DOWNLOAD MorganStanley '3456 Sent: Feb. 18, 2010

These samples highlight the value of snaplets because they indicate aclear action for the user to take with a specific account. Like alerts,snaplets are designed for easy scanning; however, a higher degree ofreformatting has pulled the most crucial information out. Additionally,the bold faced text may be a link, or button, to launch task assistance,discussed below, for easily completing the snaplet's required action.

In summary, the architecture of system 100 and the components andmechanisms through which it affords an easy way to provide a householdmanagement system with a graphical timeline display of bills. In anotherembodiment, the graphical timeline can be understood as a visualizationof the snaplets for billing. Additional aspects of the system will bedescribed in greater detail with reference to the sample user interfacescreens and process flow diagrams in the subsequent figures.

User Interface

The system, in accordance with an embodiment, will be discussed withreference to FIGS. 3-10 showing the user interface of one embodiment.These user interfaces could be displayed on the display 160 coupled tocomputer 131 or other displays associated with other end points 130. Allof the user interface figures are shown without browser or operatingsystem user interface elements for simplicity.

FIG. 3 shows a user interface for one embodiment of the system. Oneuseful feature of this user interface is every known bill for theregistered user, or system account, is shown in a single time-organizedview within areas 1210-1230. Specifically, both paid and unpaid actualbills are included (area 1210), anticipated bills (area 1220) as well asless regular, or non-recurring, bills for the time period are all in oneuser interface. Further, within each area, the bills are organized bydate, e.g. next due bill first and most distant due bill at the bottom.The shown grouping is just one embodiment, other embodiments might mixcategories of bills and use other notations to delineate between actualversus anticipated bills.

Notably, this user interface has a visual indication of the due dates(see timelines 1360 on FIG. 4 for a more detailed view) that is not“stacked up” on a single timeline. But, because the user interface inone embodiment focuses on one month of bills, the timelines provide agood visual indication of the timing of bill payments. Additionally,while the user interface of FIG. 3 is targeted for a web browserassociated with a computer, e.g. display 160 on computer 131, the samebasic approach can be applied to other end points 130 and theirassociated displays for providing a better timeline for bills.

The features and functionalities of the web interface 1200 and thevarious areas 1210-1260 of the web interface will be described ingreater detail in connection with FIGS. 4-7.

FIG. 4 shows a user interface for the bills timeline for an embodiment.Specifically, area 1210 of FIG. 3 is shown in greater detail. Notablyfor each bill (bills 1310, 1312, 1314, 1416, 1318, 1320, 1322, 1324,1326, 1328 and 1330), an account identifier is shown (e.g. icon ofbiller, biller name, user assigned nickname, and/or partial or completeaccount number) together with a timeline (from timelines 1360) proximateto the account identifier. Additionally, some embodiments may includeexplicit indication of whether the bill is an e-bill, mail, or paper inthe account section. In the shown embodiment, a background box isincluded to visually group information about a single bill cohesively.Additionally, in this embodiment, the color of the box indicates thepayment status grey for paid bills (e.g. bill 1316, bill 1320, and bill1330) and blue for unpaid bills. This helps focus user attention on theactions required while still providing information about all bills inone place. For each bill an optional indicator (indicators 1350) isshown that reflects the payment status with an icon according to oneembodiment, e.g. late, paid, due (within 7 days), automatic payment set,scheduled (optionally with date of payment), and alert for missing bill(anticipated bill has not been received within some predeterminedexpectation tolerance, e.g. +/−4 days). Within each timeline intimelines 1360, a date line is shown, e.g. date line 1362 for thetimeline associated with bill 1312. The date line helps visuallyposition the bill within the entire time period covered by the display.In one embodiment, the default display covers one month, e.g. 30-31days.

In the shown embodiment, the date lines are focused on providing dateinformation relative to other bills. However, other embodiments, mayencode additional information in the date line using color, shape,height, and/or other differentiating characteristics. For example, theamount of the bill relative to other bills in the report might beindicated by the height of the date line. Bills that fall outside of thestandard amount for that account might be in a different color to drawthe user's attention.

For unpaid bills, task assistance is available via user input on taskassist 1364. See U.S. Provisional Patent Application 61/434,508(entitled “Method and Apparatus for Inbound Message Management” assignedto Connexive, Inc. and having Martin Lefebvre as the first inventor) forone implementation of task assistance. For automatically identifiedbills, the underlying message(s) that caused the bill entry to becreated can be viewed via user input on bill notice display 1374. Thiscan overlay a dialog box/display on the web interface 1200 to enablereview of the message(s). More generally, in instances where a dialogbox or display is referred to, embodiments could navigate to anotherbrowser tab or browser window. For manual bills, user input on manualbill edit 1372 can enable the user to modify aspects of the manuallyentered bill. Additionally, for any bill entry, details can be requestedvia user input on the details request 1376.

FIG. 5 shows a user interface for the details view for an embodiment,specifically detail interface 1600 shows the details 1610 for bill 1326.There is also a hide details link 1620 to hide the details. The detailsinclude additional information about the institution, institutionaccount and/or bill. In one embodiment this includes billing history,e.g. text or graph (shown), payment account, billing institution website information (username/password hint). Other embodiments may includeadditional information. For example, the details area might includeaffiliate, or general, marketing such as incentives by the institutionto switch to paperless billing and/or automatic payment. Other uses ofthe space might include recommending alternative (cheaper) providers ofsimilar services, e.g. “Consider switching to Verizon”. In otherembodiments, advertising may be displayed elsewhere in the web interface1200.

Returning to FIG. 4, the display in area 1210 is blending primarilyautomatically identified information with manual information of twokinds: (a) manually entered bills and (b) manually supplemented detailsthat were missing (e.g. payment amounts and/or due dates) that cansometimes be missing from a message from a billing institution and whichthe system 120 may also attempt to estimate. For example, several of thedue dates in the timeline include estimates, e.g. bill 1328 has theNovember 22 due date estimated.

FIG. 6 shows a user interface for the anticipated and non-recurringbills timeline for an embodiment, among the bills shown in FIG. 6 arebills 1710, 1712, 1714, 1716, 1718 and 1720. Specifically, the areas1220 and 1230 of FIG. 3 are shown in greater detail. A similar displayset up as was described in connection with bills for FIG. 4 is used inboth areas with an account identifier proximate to a timeline. Notablyin FIG. 6, anticipated bills can be reviewed by the user, e.g. userinput on view explanation 1750 to trigger human understandableinformation such as dialog 1900 (see FIG. 8), explaining why a bill isanticipated. Additionally shown in this figure is a mechanism for userinput to edit accounts via user input on edit account 1760. In oneembodiment, when the system 120 identifies the first bill from a billinginstitution, the “Review” user input point is shown to encourage usersto provide additional context about the account, e.g. nicknames, accountnumbers, payment methods, etc.

In one embodiment, a cutoff of 18 days is used to determine whichanticipated bills to show in the anticipated bill section. Note that asdiscussed supra, in some embodiments this cutoff may be used for onlycertain types of anticipated bills. Bills that are anticipated between19-30 (or 31) days that would otherwise, normally be reflected in thereport are filtered out. This helps remove clutter and or double-entriesof bills from the display. For example, bill 1316 for an AT&T phoneservice would be confusing if it appeared both in the actual billsection (area 1210) as well as in the anticipated bill section. A cutoffof 18 days forward look helps reduce clutter by filtering out the nextanticipated bill while the current bill is on the display. Otherembodiments might perform filtering using a de-duplication rule asopposed to a date-based cutoff.

Additionally, the particular grouping of bills into these threecategories of actual, anticipated and non-recurring can be user and/orsystem customizable. More generally, the horizontal (or potentiallyvertical) display of the different bills with separate timelines offersusers an improved comprehension of bills versus a single timeline. Inone embodiment there are two types of anticipated bills: (i) thoseanticipated from the message stream, e.g. crystal ball bills, seediscussion of FIG. 11, and (ii) manually entered bills. For crystal ballbills, an anticipated bill is moved to the timeline when a billnotification message is received. If a bill is not received within acertain tolerance window (say 7 days) of the anticipated date, a flagcan be raised using a suitable indicator in the anticipated bill area1220 as one done with indicators 1350 for area 1210 as discussed inconnection with FIG. 4. An indicator can alert a user that ananticipated bill has not been received. For manually entered bills, inone embodiment, the bills are moved into the main timeline eighteen (18)days before the due date. This timing may be particularly helpfulbecause it may correspond with when the underlying paper bill would bereceived.

FIG. 7 shows a user interface for an embodiment, the areas 1240-1260 ofFIG. 3 are shown in greater detail. Area 1240 provides a summary ofrecent account balances for the payment accounts used to pay bills. Theinformation about the balances can be extracted from messages and/ordirectly obtained from financial institutions. In area 1250, a summaryof the timeline in narrative form is shown. In this embodiment, thenumber of unpaid due bills is summarized, the number of new accountswhere manual supplemental input can improve results is shown (e.g.adding a nickname for an account and/or clarifying the computerrecognized date). In some embodiments, some or all of the buttons inarea 1250 are active, e.g. user input on “Go to Pay” would start a taskassist process for paying the nearest in time unpaid bill. In theexample of FIG. 3, this would be the bill 1310, a late bill for PG&E.

Area 1260 shows a chart of anticipated expenses over the period of thetimeline, e.g. 30 days. So in this example, you can see about $1,300worth of bills are due over the next 30 days. In some embodiments, area1260 might be expanded to include income and expected account balanceinformation. Income information can be obtained from messages aboutdirect deposits (wages, social security, etc.) and/or directly fromfinancial institutions. Additionally, anticipated payments could beincluded. Thus in one embodiment you could see at a glance your cashposition forecast for the timeline period at an easy glance. This wouldhighlight periods when the user might not have enough cash to meet allof their obligations.

FIG. 8 shows a user interface for an explanation of an anticipated billfor an embodiment. As discussed previously, the dialog 1900 could beshown to explain an anticipated bill to a user in human understandableterms upon user input on view explanation 1750 of FIG. 6.

FIG. 9 shows the edit account dialog 2000, this allows for usersupplementation of the automatically identified information. Forexample, accounts can be assigned nicknames. This dialog can bedisplayed overlaid on the screen in response to user input on the editaccount 1760 button of FIG. 6. In one embodiment, the data that can beprovided includes account name (or nickname); account number (or accountidentifier); account type, e.g. utility, loan, credit card; username;password hint; payment method; and/or autopay indicator. In someembodiments the system imposes some limits on the user's ability to addand/or modify account numbers. For example, in the case of utilityaccounts, the system may allow the user to enter the complete accountnumber for ease of reference without allowing him and/or her to modifythe trailing numbers that were automatically extracted from an email orother data source as this could create difficulties for automaticmessage identification. As another example, in the case of credit cardaccounts and/or other financial accounts, the system may prevent usersfrom entering a complete account number as this may pose a potentialsecurity risk to such users.

FIG. 10 shows the bill edit dialog 2100 and can be displayed (blank asshown) in response to a user input on “add a bill” or partiallycompleted in response to user input on the manual bill edit 1372 buttonof FIG. 4. As discussed supra, creation of a bill will create (or belinked to) one or more institution accounts and institutions. Thiscreation of accounts and institutions can occur automatically in thebackground without direct user input. Note that the process of creatinga bill, FIG. 10, has similar inputs to the account edit dialog, FIG. 9,as well as specific fields to allow the user to input the specific billamount, due date, and recurrence (with option to specific therecurrence).

The use of the term dialog in relation to FIGS. 8-10 refers to inputmechanisms as opposed to the mandatory use of an operating system dialogbox. In one embodiment, the dialogs are displayed by overlaying a partof the browser window to focus the user in the specific input area.

Message Acquisition and Processing

FIG. 11 is a process flow diagram for message acquisition and processingaccording to one embodiment. FIG. 11 includes a process 2200 that startsat step 2010. The result of process 2200 is to generate the data forareas 1210-1230 of FIG. 3 and in some embodiments, the output itself,e.g. HTML code. Additionally, while process 2200 is described in alinear fashion, the process can occur in parallel with various stepsoccurring asynchronously and the results at step 2250 reflecting thethen available information.

Step 2010 includes the identification of messages (e.g. messages 212 ofFIG. 2) relating to bills. Depending on the content of the message someor all of the following three pieces of data may be missing: accountnumber (or account identifier), amount due, and due date. In oneembodiment, the web interface 1200 of FIG. 3 allows users to manuallyenter some or all of the missing data for a bill.

At step 2220, entries for actual bills are created, e.g. in the bills252. Missing data may be estimated and marked as an estimate, e.g. a duedate approximation could be generated by the system 120 but flagged asan estimate. For example, due date estimation in the United States forcredit card type bills could be set to 21 days after the date of theemail message. Other industry, or biller, type rules could be applied.For example, utility bills might be 25 days while credit cards are 21,etc. In still other embodiments, information about due dates for a givenbilling institution from other users' messages (or manual user entry)may inform the due date setting, e.g. other users have Chase bank creditcard bills due on average 22.5 days after the email, so future Chasebank credit card bills get set to a 22 day due date vs. 21 for othercredit card accounts. Additionally, it should be noted that a singlebill entry may be composed from multiple messages, for example a paymentalert for a past bill could be a source of amounts paid/due and duedate. That could in turn drive estimations going forward.

In some embodiments, at step 2220 additional missing data, e.g. amountdue, can be estimated. Many bills have highly regular recurrence amounts(sometimes with seasonal variations). This information from prior billsand payments can be used to help estimate the amount due in theseembodiments.

At step 2230, de-duplication of bills is carried out. This can often beparticularly helpful in the case of bills that are proxied by otherproviders. For example, a user may receive messages from both theircredit card company and their bank's online bill payment service aboutthe same bill. In some embodiments, de-duplication is purely automatic,e.g. based on similar due dates/amounts/account identifiers. In otherembodiments, user input can identify duplicative accounts for thesystem. For example, a notice of a credit card bill for American Expressaccount ending in 2001 is received from American Express. In a similartime frame, a notice is received from Bank of America that an AmericanExpress bill is ready to view for an American Express account ending in2001. Thus, AMEX-2001 can be identified as a bill at Bank of Americabill pay and that the two bills are the same bill for a singleunderlying account. Information from both messages can also be used tocompile the timeline for that bill. If one of the two emails does notcontain the account identifier, the two bills can be identified as thesame based on the list of accounts that the user has with AmericanExpress as well as the dates of the two emails.

At step 2240, anticipated future bills are estimated. As seen in FIG. 8a portion of this functionality can be exposed to users as a “crystalball” feature. As discussed, supra, there may be two types ofanticipated bills in some embodiments, e.g. manually entered vs.predicted with different display rules and practices. In one embodiment,only estimated bills within 18 days of the present date are reflected inthe timeline at step 2250. Other date cutoffs could be used, but 18strikes a useful balance for a thirty day timeline with monthly billsbetween the prior bill naturally “falling off” as paid and the newbill's arrival being projected.

Bill estimation at step 2240 can be done through one or more differentapproaches. In one embodiment a statistical approach based on computingthe mean number of days between receipt of prior bills is used. In avariation of this embodiment, the data is only used if the standarddeviation for the mean is sufficiently low.

In another embodiment, a matching approach using several commonintervals is used. For example, in one embodiment the following commonintervals are used: monthly, bi-monthly, quarterly, bi-annually, andannually. Using this approach, you compare the historically receivedpattern of bills (ignoring day of receipt and focusing only on month)versus the pattern and select the best match. This approach is lesssensitive to small deviations in bill delivery since a bill any day inMarch within the tolerance is a March bill, and so on. This can becomputed by looking at deviations from the same-day-next month, forexample if for account X there is a bill received on March 14 and asecond bill received April 17, this is considered to be exactly onemonth apart (13% number of days tolerance in one embodiment or +/−4days). Then you look at the length of time in whole months between billsconsidered having the same day so you will have a set of integer billingintervals, e.g. (12, 3, 3, 3) (annual newspaper subscription switched toquarterly) or (7, 3) (credit card bill for an infrequently used creditcard). If the GCD of the intervals is examined that can identify thebilling frequency, e.g. GCD(12, 3, 3, 3)=3 vs. GCD(7,3)=1. In thisembodiment there are several options if no common intervals match well:make no predictions (e.g. treat as non-recurring), treat the bill asmonthly, or prompt the user for input (this could either be a blockingrequest, e.g. force the user to classify the bill before next display,or non-blocking, e.g. treat as non-recurring but prompt for the user tomanually correct in the user interface). In some embodiments, thematching is further modified by information about the type of account,e.g. utility vs. credit card vs. property tax. In other embodiments,information about other bills of a similar nature for other users in thesystem can inform the matching, e.g. if most users receive this billmonthly and no pattern is matching for you, treat the bill as monthlyanyhow.

In some instances, this approach can be used to predict that an accountwas closed, e.g. no bills on a monthly account for more than x months.Such an approximation may result in user prompts to confirm the decisionor simply a removal of account from regular displays until additionalmessages or bills from the account arrive.

Finally, at step 2250 the information generated from the prior steps canbe consolidated into the timeline view the web interface 1600 of FIG. 3.This can be done using one or more queries into a database storing theresults of the prior steps of process 2200 and/or direct operation onobjects generated by the prior steps. Output generation of the HTML canbe done using one or more template languages or direct generation.

Conclusion and Additional Embodiments

We have now described a system and processes that afford an easy way toprovide a household management system with a graphical timeline displayof bills.

Some additional embodiments and features include:

-   -   In some embodiments, the web interface 1200 may include a        summary indicator highlighting the general positive vs. negative        trend during the report period for balances in (versus out),        e.g. using a +/−, smiley/frown, and/or other indication.    -   In some instances the entries for a bill, and/or the summary        area, may indicate if you are below a minimum balance        requirement or over a credit limit for an account.    -   In some embodiments, the system may provide timing advice on        when to make payments (or how, e.g. use this rewards card to pay        that bill), to avoid penalties and/or to improve cash flow by        delaying payment for as long as possible.    -   In some embodiments, the system may provide a recommended credit        card to use for an upcoming large purchase to help improve cash        flow. Alternatively, the user may be able to readily deduce that        by simply examining the anticipated due dates for their credit        cards.    -   In some embodiments, the web interface 1200 provides filtering        to limit the display, e.g. based on categories of bills (credit        card only) and/or other criteria. Still other embodiments may        allow for a longer time horizon, e.g. 60-90 days to be viewed.    -   In some embodiments, the web interface 1200 may provide a more        compact view than the shown example with each bill on a single        line with the account identifier and the associated timeline in        proximity and then the next bill more closely underneath/to the        side (for left-to-right scripts, in such cases the timeline        might be vertically oriented as well).    -   Some embodiments may require payment for access to additional        features, e.g. “pro” accounts vs. free accounts, or business vs.        personal accounts, and/or access to certain features, e.g.        ability to add custom rules.    -   Some embodiments may differentiate between multi-device (iOS        application vs. computer web based) access, e.g. only premium        account can access the data across multiple devices.    -   Some embodiments may offer document (e.g. bill)        storage/retention capabilities for helping clip and store        documents. The web document clipping described in U.S.        Provisional Patent Application 61/434,508 could be used to        implement this functionality.    -   Some embodiments may offer OCR and scraping of documents,        especially scanned documents, to identify bills. For example, a        (cameraphone or tablet) picture of a paper bill could be scraped        to generate the manual bill entry with minimal human        intervention.    -   As noted, in some instances the operator of the system 120 may        partner with institutions for affiliate fees to encourage        certain customer behaviors, e.g. go paperless/setup autopay.

Any data structures and code described or referenced, above, are storedaccording to many embodiments on a computer-readable storage medium,which may be any device or medium that can store code and/or data foruse by a computer system. This includes, but is not limited to, volatilememory, non-volatile memory, application-specific integrated circuits(ASICs), field-programmable gate arrays (FPGAs), magnetic and opticalstorage devices such as disk drives, magnetic tape, CDs (compact discs),DVDs (digital versatile discs or digital video discs), or other mediacapable of storing computer-readable media now known or later developed.

The preceding description is presented to enable the making and use ofthe invention. Various modifications to the disclosed embodiments willbe apparent, and the general principles defined herein may be applied toother embodiments and applications without departing from the spirit andscope of the invention. Thus, the invention is not intended to belimited to the embodiments shown, but is to be accorded the widest scopeconsistent with the principles and features disclosed herein. The scopeof the invention is defined by the appended claims.

What is claimed is:
 1. A computer-implemented method for displaying aplurality of bills, each bill having a corresponding bill due date, themethod comprising: displaying using a computer, across a first webinterface, an account identifier for each bill in the plurality ofbills; displaying using the computer a plurality of timelines withrespective date line indicators, each timeline for a respective bill inthe plurality of bills: the date line indicator graphically representingthe due date of the respective bill within the timeline, and thetimeline disposed proximate to the account identifier; wherein theplurality of timelines share a common scale and visual alignment; foreach bill, displaying using the computer an item comprised of at leastone of a link and a button, the item operative to trigger the display bythe computer of at least parts of an underlying bill source that causedthe timeline for the respective bill to be created or operative totrigger display of a bill payment dialogue; and displaying theunderlying bill source or the bill payment dialogue across a second webinterface overlaid on the first web interface.
 2. Thecomputer-implemented method of claim 1, further including, for eachtimeline, graphical encoding of a payment status of the respective billrepresented by the timeline.
 3. The computer-implemented method of claim2, wherein the graphical encoding of the payment status of therespective bill is color-coded.
 4. The computer-implemented method ofclaim 2, wherein the graphical encoding of the payment status of therespective bill is an icon.
 5. The computer-implemented method of claim1, further including assigning a color to one of the timeline and thedue date indicator, based on a condition selected from the setcomprising: paid, unpaid, size of payment, and autopay set.
 6. Thecomputer-implemented method of claim 1, further including, responsive toreceiving a user request, displaying a billing history for a selectedaccount as a bar graph.
 7. The computer-implemented method of claim 1,further including, in addition to displaying timelines for the pluralityof bills, displaying timelines for a plurality of anticipated bills inaccounts that were paid periodically in prior periods, for which nocurrent bill has been registered.
 8. A computer-implemented method ofgenerating a display of a plurality of bills having due dates, themethod including: at a server, generating data, across a first webinterface, for display of a plurality of horizontal timelines eachrepresenting a respective bill to be paid in a time period depicted bythe horizontal timelines; wherein each horizontal timeline includes adate line indicator positioned to indicate a due date of the respectivebill; wherein the horizontal timelines are aligned so that the date lineindicators on respective timelines depict a time ordered sequence inwhich the respective bills are due to be paid; wherein a respectiveaccount identifier is visually associated with each of the respectivetimeline; for each bill, displaying using the computer an item comprisedof at least one of a link and a button, the item operative to triggerthe display by the computer of at least part of an underlying billsource that caused the timeline for the respective bill to be created oroperative to trigger display of a bill payment dialogue; displaying theunderlying bill source or the bill payment dialogue across a second webinterface overlaid on the first web interface; and transmitting the datafor display to a workstation via a network.
 9. The computer-implementedmethod of claim 8, further including, for each timeline, graphicalencoding of a payment status of the respective bill represented by thetimeline.
 10. The computer-implemented method of claim 9, wherein thegraphical encoding of the payment status of the respective bill iscolor-coded.
 11. The computer-implemented method of claim 9, wherein thegraphical encoding of the payment status of the respective bill is anicon.
 12. The computer-implemented method of claim 8, further includingassigning a color to one of the timeline and the due date indicator,based on a condition selected from the set comprising: paid, unpaid,size of payment, and autopay set.
 13. The computer-implemented method ofclaim 8, further including, responsive to receiving a user request,displaying a billing history for a selected account as a bar graph. 14.The computer-implemented method of claim 8, further including, inaddition to displaying timelines for the plurality of bills, displayingtimelines for a plurality of anticipated bills in accounts that werepaid periodically in prior periods, for which no current bill has beenregistered.
 15. A computer-implemented method of displaying of aplurality of bills having due dates, the method including: displaying,across a first web interface, a plurality of horizontal timelines eachrepresenting a respective bill to be paid in a time period depicted bythe horizontal timelines; wherein each horizontal timeline includes adate line indicator positioned to indicate a due date of the respectivebill; wherein the horizontal timelines are aligned so that the date lineindicators on respective timelines depict a time ordered sequence inwhich the respective bills are due to be paid; wherein a respectiveaccount identifier is visually associated with each of the respectivetimeline; for each bill, displaying using the computer an item comprisedof at least one of a link and a button, the item operative to triggerthe display by the computer of at least parts of an underlying billsource that caused the timeline for the respective bill to be created oroperative to trigger display of a bill payment dialogue; and displayingthe underlying bill source or the bill payment dialogue across a secondweb interface overlaid on the first web interface.
 16. Thecomputer-implemented method of claim 15, further including, for eachtimeline, graphical encoding of a payment status of the respective billrepresented by the timeline.
 17. The computer-implemented method ofclaim 8, further including assigning a color to one of the timeline andthe due date indicator, based on a condition selected from the setcomprising: paid, unpaid, size of payment, and autopay set.
 18. Thecomputer-implemented method of claim 8, further including, responsive toreceiving a user request, displaying a billing history for a selectedaccount as a bar graph.
 19. The computer-implemented method of claim 8,further including, in addition to displaying timelines for the pluralityof bills, displaying timelines for a plurality of anticipated bills inaccounts that were paid periodically in prior periods, for which nocurrent bill has been registered.